Summary

File transfer (use_file_transfer) staged every source file at {staging_dir}/{source_file_relative_path}. When two source files resolve to the same relative path, they share one staging file, which breaks syncs:

1. Source downloads file A to /staging/files/Untitled document.docx, emits a record referencing it.
2. Destination reads it, uploads it, then deletes the staging file (FileChunkTask → localFile.delete()).
3. Source downloads file B (a different source file) to the same path and emits another record.
4. Whichever side loses the race fails: the destination hits java.io.FileNotFoundException: /staging/files/Untitled document.docx (No such file or directory), or the destination reads bytes of B for record A.

This is easy to hit on Google Drive (duplicate document names are allowed, and exported Google-native docs are named {name}.{ext}) and on any source when preserve_directory_structure is disabled and the same file name exists in several folders.

Fix: namespace the local staging path under a unique subdirectory, leaving source_file_relative_path (and therefore the destination object key) unchanged:

-local_file_path = path.join(staging_directory, file_relative_path)
+local_file_path = path.join(staging_directory, uuid.uuid4().hex, file_relative_path)

Because LOCAL_FILE_PATH comes from AbstractFileBasedStreamReader._get_file_transfer_paths, this covers the base upload() as well as the readers that call the helper themselves (source-google-drive, source-s3, source-microsoft-sharepoint) with no connector-side change.

The Check: source-google-drive CI job here fails on test_upload_file, which asserts the exact staging path; the test-only update it needs is in airbytehq/airbyte#82754 (same for source-microsoft-sharepoint; source-s3 already asserts with endswith). That check should go green once the monorepo PR merges.

Out of scope but worth flagging: duplicate relative paths still map to a single destination object key, so one file overwrites the other in the destination. That is inherent to path-mirroring naming and is not what makes the sync fail.

Resolves https://github.com/airbytehq/oncall/issues/12851:

• https://github.com/airbytehq/oncall/issues/12851

Declarative-First Evaluation

Not applicable: the bug is in the Python CDK's file-based stream reader (staging path construction), not in a declarative connector manifest. No declarative feature can influence where the CDK stages a transferred file.

Test Coverage

• New test_staging_paths_are_unique_per_file in unit_tests/sources/file_based/test_file_based_stream_reader.py asserts that two files resolving to the same relative path get identical file_relative_path but distinct local_file_path (parametrized for the duplicate-name and preserve_directory_structure: false cases). It fails on main (both calls return the same local path).
• test_preserve_sub_directories_scenarios updated: it now asserts the local path is {staging_dir}/{unique_subdir}/{expected_relative_path} instead of a hardcoded path.
• poetry run pytest unit_tests/sources/file_based -q → 796 passed, 1 skipped. ruff check, ruff format --check, and mypy pass.

Versioning

No connector version bump or changelog entry: this repo publishes from release notes, and pyproject.toml version is computed dynamically. Non-breaking — no schema, spec, stream, or state change; only the ephemeral local staging path changes, and it is communicated to the destination via staging_file_url in the same record.

Link to Devin session: https://app.devin.ai/sessions/8ef791c2602147a2951781e0af756828